Skip to content

loading animation fixes#423

Draft
phanen wants to merge 2 commits into
sudo-tee:mainfrom
phanen:fix/loading-animation-attach-busy-spinner
Draft

loading animation fixes#423
phanen wants to merge 2 commits into
sudo-tee:mainfrom
phanen:fix/loading-animation-attach-busy-spinner

Conversation

@phanen

@phanen phanen commented Jun 23, 2026

Copy link
Copy Markdown
Contributor
  • fix(animation): don't drive the spinner from local HTTP activity
  • fix(animation): hydrate spinner state via sync on (re)attach

phanen added 2 commits June 24, 2026 00:28
Problem: the thinking spinner flashed for a few frames on every UI
open. M.render and the timer on_tick both gated the spinner on
state.jobs.is_running(), and on_running_change would M.start the
spinner whenever a new request bumped job_count. But
server_job.call_api unconditionally calls state.jobs.increment_count()
for every HTTP request, including pure queries (ensure_server,
list_sessions, sync_from_status). Toggle on issues 3-4 such queries
in quick succession, so M.start fired for each one and M.stop
fired when the response decremented, blinking the spinner on and
off even though no model was actually thinking.

Solution: replace the jobs.is_running() gate with a new
M._should_animate() that returns true only when status_data is
non-idle and tagged with the active session's sessionID.
on_running_change keeps M.stop as a safety net but no longer calls
M.start. job_count remains the signal for footer UI like "<C-c>
to cancel"; it just no longer drives the spinner. status_data is
now tagged with status_session_id so _should_animate can tell
stale data apart from a real server event for the current session.
Problem: after restarting vim or attaching to a long-running
server, the thinking spinner did not come up while the active
session was still processing, and toggle off then on lost it
permanently. The SSE stream is event-driven on the server side:
it registers a listener at connect time and only forwards events
that fire afterwards, so a busy transition that happened before
the attach was never replayed. vim never asked for the current
state either, and toggle off wiped the only client-side copy
status_data held. Two races compounded this: sync resolving just
before set_active would wipe the freshly installed busy status
through its on_active_session_change listener, and sync resolving
before set_active would no-op entirely and leave the spinner off
indefinitely.

Solution:
- Add OpencodeApiClient:list_session_status (GET /session/status)
  and have event_manager call it on initial subscribe so a
  (re)attach actively queries current state.
- Add loading_animation.sync_from_server() called from setup().
  It caches the response on M._animation.last_status_map and only
  replays the entry for the current active session, so cross-
  session events cannot pollute the spinner.
- on_active_session_change replays from last_status_map when
  active_session is set after sync resolved, recovering without
  another round trip. It also stops clearing status_data on the
  first (nil -> X) assignment, so the freshly installed busy status
  survives the listener that fires a few ticks later.
- setup() no longer starts the spinner from preserved status_data
  (which can be stale); only the server-confirmed status starts
  it. teardown keeps status_data and status_session_id intact so
  the next setup can resume from the cached server state.
- on_session_status rejects events with no active session or a
  mismatched sessionID so SSE events from other sessions cannot
  pollute state.

This builds on the previous commit (loading_animation no longer
drives the spinner from local HTTP activity); _should_animate
remains the single source of truth, now fed by server status.
@phanen phanen marked this pull request as draft June 23, 2026 16:31
@sudo-tee

Copy link
Copy Markdown
Owner

Thanks for the PR,

This looks like a nice improvement. I will do some testing throughout the day

@phanen

phanen commented Jun 25, 2026

Copy link
Copy Markdown
Contributor Author

there‘s still edge case spinner won‘t disappear and cannot stably reproduce

@sudo-tee

Copy link
Copy Markdown
Owner

No stress, I tried it a little bit and for the most part it works pretty well. But I'll wait on merging it.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants